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1. REAL PARTY IN INTEREST 

The real party in interest is assignee Sybase, Inc. located at One Sybase Drive, 
Dublin, CA 94568. 

2. RELATED APPEALS AND INTERFERENCES 

There are no appeals or interferences known to Appellant, the Appellant's legal 
representative, or assignee which will directly affect or be directly affected by or have a 
bearing on the Board's decision in the pending appeal. 

3. STATUS OF CLAIMS 

The status of all claims in the proceeding is as follows: 
Rejected: Claims 1-48 

Allowed or Confirmed: None 
Withdrawn: None 
Objected to: None 
Canceled: None 

Identification of claims that are being appealed: Claims 1-48 

An appendix setting forth the claims involved in the appeal is included as Section 
8 of this brief. 

4. STATUS OF AMENDMENTS 

One Amendment has been filed in this case. Appellant filed an Amendment on 
May 16, 2008 in response to a non-final Office Action dated February 8, 2008. In the 
Amendment filed on May 16, 2008, the pending claims were amended in a manner that 
Appellant believes clearly distinguished the claimed invention over the art of record, for 
overcoming the art rejections. In response to the Examiner's Final Rejection dated 
August 27, 2008 (hereinafter "Final Rejection") finally rejecting Appellant's claims, 
Appellant filed a Notice of Appeal. Appellant has chosen to forego filing an Amendment 
After Final as it is believed that further amendments to the claims are not warranted in 
view of the art. Accordingly, no amendments have been entered in this case after the date 
of the Final Rejection. 
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5. SUMMARY OF CLAIMED SUBJECT MATTER 

Appellant asserts that the art rejections herein fail to teach or suggest all of the 
claim limitations of Appellant's claimed invention, where the claimed invention is set 
forth in the embodiment in independent claim 1: A system for consolidating financial 
transaction information from multiple sources for presentation to a user (see e.g., 
Appellant's specification, paragraph [0015], paragraphs [0057]-[0058], paragraph [0060]; 
paragraphs [0063]-[0069]; also see generally, Fig. 3 and Fig. 4), the system comprising: a 
file importer (see e.g., Appellant's specification, paragraph [0015], paragraphs [0063]- 
[0065]; Fig. 4 at 420 (file importer)) for importing data files from a first source and 
processing each data file to create parsed information for each transaction present in the 
data file (see e.g., Appellant's specification, paragraph [0015], paragraphs [0064]-[0065], 
paragraphs [0081]-[0082]; Fig. 5A at 501-503; also see generally, Fig. 4 at 420, 430, 445) 
and represent any additional information present in the data file in Extensible Markup 
Language (XML) format (see e.g., Appellant's specification, paragraph [0015], paragraph 
[0066], paragraph [0084]; Fig. 5 A at 505-506), a data consolidator (see e.g., Appellant's 
specification, paragraph [0015], paragraph [0063], paragraphs [0065]-[0066], paragraph 
[0068]; Fig. 4 at 450 (data consolidator)) for receiving parsed information from the file 
importer (see e.g., Appellant's specification, paragraph [0015], paragraph [0063], 
paragraphs [0065] -[0066], paragraph [0084]; Fig. 5 A at 504), consolidating said parsed 
information with transaction information from a user-accessible system to create 
consolidated transaction records (see e.g., Appellant's specification, paragraph [0015], 
paragraphs [0071]-[0072]; Fig. 4 at 470, 445, 420, 430 and 450), assigning a unique 
identifier to each consolidated transaction record for an account (see e.g., Appellant's 
specification, paragraph [0015], paragraphs [0069] -[0070], paragraph [0084]; Fig. 5A at 
504), and storing said consolidated transaction records (see e.g., Appellant's specification, 
paragraph [0015], paragraphs [0065]-[0067], paragraph [0071], paragraph [0084]; Fig. 4 
at 460; Fig. 5A at 506), wherein consolidating said parsed information includes removing 
transaction information derived from the user accessible system that is duplicated in said 
parsed information from the data files (see e.g., Appellant's specification, paragraph 
[0015], paragraph [0072], paragraph [0085]), and a reporting module (see e.g., 
Appellant's specification, paragraph [0015], paragraph [0063], paragraphs [0072] -[0073]; 
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Fig. 4 at 480 (reporting module)) for receiving a request for financial transaction 
information for a particular account and presenting consolidated transaction records for 
the particular account to the user in response to the request (see e.g., Appellant's 
specification, paragraph [0015], paragraph [0063], paragraphs [0072] -[0073], paragraphs 
[0085]-[0086]; Fig. 5B at 507-511)) wherein the user may navigate through said 
consolidated transaction records based upon said unique identifier (see e.g., Appellant's 
specification, paragraph [0015], paragraph [0060], paragraphs [0068] -[0070], paragraph 
[0086]; also see generally, paragraphs [0074]-[0078]). 

Appellant additionally asserts that the art rejections herein fail to teach or suggest 
all of the claim limitations of Appellant claimed invention, where the claimed invention 
is set forth in the embodiment in independent claim 21: A computer- implemented 
method for consolidating and presenting financial information to a user (see e.g., 
Appellant's specification, paragraph [0016], paragraphs [0057]-[0058], paragraph [0060]; 
paragraphs [0063]-[0069]; also see generally, Fig. 4 and Figs. 5A-B), the method 
comprising: importing data files of different types (see e.g., Appellant's specification, 
paragraph [0016], paragraphs [0064]-[0065], paragraphs [0081]-[0083]; Fig. 5A at 501; 
also see generally, Fig. 4 at 420, 430, 445), for each particular type imported, loading a 
file adapter suited for processing that particular type (see e.g., Appellant's specification, 
paragraph [0016], paragraph [0065], paragraph [0083]; Fig. 4 at 430, Fig. 5A at 502- 
503), for each imported data file, creating parsed information from the data file that 
identifies each transaction present in the data file with a unique sequence number, and 
that represents any additional information present in the data file in XML format (see 
e.g., Appellant's specification, paragraph [0016], paragraphs [0065]-[0066], paragraph 
[0069] (sequence number) paragraph [0084]; Fig. 5A at 504-505; also see generally, Fig. 
4 at 420, 430, 445), creating consolidated financial information by storing all parsed 
information in a consolidation repository (see e.g., Appellant's specification, paragraph 
[0016], paragraphs [0065]-[0067], paragraph [0071], paragraph [0084]; Fig. 4 at 460; Fig. 
5A at 506), including removing financial information derived from a user accessible 
system which is duplicated in said parsed information (see e.g., Appellant's specification, 
paragraph [0016], paragraph [0072], paragraph [0085]), receiving a user request at the 
user-accessible system for information about a particular financial account (see e.g., 
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Appellant's specification, paragraph [0016], paragraphs [0072]-[0073], paragraphs 
[0085]-[0086]; Fig. 5B at 507), and in response to the user request, determining financial 
information in the user-accessible system and the consolidation repository that is most 
current for the particular financial account, and presenting that financial information to 
the user (see e.g., Appellant's specification, paragraph [0016], paragraphs [0072]-[0073], 
paragraphs [0085]-[0086]; Fig. 5B at 508-511)). 

Appellant further asserts that the art rejections herein fail to teach or suggest all of 
the claim limitations of Appellant claimed invention, where the claimed invention is set 
forth in the embodiment in independent claim 36: A computer-implemented system for 
consolidating and presenting financial information to a user (see e.g., Appellant's 
specification, paragraph [0017], paragraphs [0057] -[005 8], paragraph [0060]; paragraphs 
[0063]-[0069]; also see generally, Fig. 3, Fig. 4, Figs. 5A-B), comprising: a file importer 
for importing data files of different types (see e.g., Appellant's specification, paragraph 
[0017], paragraphs [0063]-[0065]; Fig. 4 at 420 (file importer)), a plurality of file 
adapters, each file adapter suited for processing a particular type of data file (see e.g., 
Appellant's specification, paragraph [0017], paragraph [0065], paragraph [0083]; Fig. 4 at 
430, Fig. 5A at 502-503), imported by creating parsed information from the data file that 
identifies each transaction present in the data file with a unique sequence number, and by 
representing any additional information present in the data file in XML format for each 
imported data file (see e.g., Appellant's specification, paragraph [0016], paragraphs 
[0065]-[0066], paragraph [0069] (sequence number) paragraph [0084]; Fig. 5A at 504- 
505; also see generally, Fig. 4 at 420, 430, 445), a consolidator for consolidating financial 
information by consolidating parsed information from imported data files with data from 
a user-accessible system, including removing transaction information derived from the 
user accessible system duplicated in said parsed information (see e.g., Appellant's 
specification, paragraph [0017], paragraphs [0065]-[0067], paragraphs [0071]-[0072], 
paragraphs [0084]-[0085]; Fig. 4 at 450, Fig. 5A at 506), a consolidation repository for 
storing consolidated financial information (see e.g., Appellant's specification, paragraph 
[0017], paragraphs [0065]-[0067], paragraph [0071], paragraph [0084]; Fig. 4 at 460; Fig. 
5A at 506), a user-accessible system for receiving a user request for information about a 
particular financial account (see e.g., Appellant's specification, paragraph [0017], 
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paragraph [0063], paragraphs [0072] -[0073]; Fig. 4 at 470, 480, Fig. 5B at 507), and a 
module for determining financial information in the user-accessible system and the 
consolidation repository that is most current for the particular financial account, and 
presenting that financial information to the user (see e.g., Appellant's specification 
paragraph [0016], paragraphs [0072]-[0073], paragraphs [0085]-[0086]; Fig. 5B at 508- 
511). 

Appellant additionally argues based on dependent claims 3, 23 and 38 which 
include a claim limitation pertaining to: a Bank Administration Institute (BAI) file 
adapter for extracting data from a Bank Administration Institute (BAI) data file (see, e.g., 
Appellant's specification paragraph [0060], paragraph [0065] (if the specified file type is 
BAI, the file importer 420 loads a BAI file adapter; see also file adapter(s) 430 (e.g., BAI 
adapter) as illustrated in Fig. 4). 

Appellant additionally argues based on dependent claims 10, 25 and 40, which 
include claim limitations pertaining to: wherein said unique identifier assigned to a 
transaction record comprises a sequence number (see, e.g., Appellant's specification at 
paragraph [0016], paragraph [0069], paragraph [0084]; see also data consolidator 450 
illustrated at Fig. 4 and assigning sequence number to each transaction at step 504 
illustrated at Fig. 5A). 

Appellant additionally argues based on dependent claim 1 1 including claim 
limitations pertaining to: a data consolidator assigning date -based sequence numbers to 
transaction records of a given type for a particular account (see, e.g., Appellant's 
specification, paragraph [0069], paragraph [0075], paragraph [0078], paragraph [0084]; 
see also data consolidator 450 illustrated at Fig. 4 and assigning sequence number to each 
transaction at step 504 illustrated at Fig. 5A). 

Appellant additionally argues based on dependent claim 12 including claim 
limitations pertaining to: a data consolidator assigning consecutive sequence numbers to 
transaction records of a given type for a particular account (see, e.g., Appellant's 
specification, paragraph [0069], paragraph [0084] (sequence number may be a 
consecutive sequence number); see also data consolidator 450 illustrated at Fig. 4 and 
assigning sequence number to each transaction at step 504 illustrated at Fig. 5A). 

Appellant additionally argues based on dependent claims 13-14, 26 and 41, which 
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include claim limitations pertaining to: a data consolidator assigning date-based 
sequence numbers to transaction records of a given type for a particular account (see, 
e.g., Appellant's specification, paragraph [0069], paragraph [0075], paragraph [0078], 
paragraph [0084]; see also assigning sequence number to each transaction at step 504 
illustrated at Fig. 5A), wherein the data consolidator is user configurable to assign a 
unique identifier to transaction records using a selected one of consecutive sequence 
numbers and date-based sequence numbers (see, e.g., Appellant's specification, paragraph 
[0069], paragraph [0075] (solution configurable so user may select either date-based or 
consecutive paging schemes), paragraph [0078], paragraph [0084]; see also, e.g., data 
consolidator 450 illustrated at Fig. 4 and assigning sequence number to each transaction 
at step 504 illustrated at Fig. 5A). 

Appellant additionally argues based on dependent claim 15 including claim 
limitations pertaining to: a data consolidator providing for undoing transaction records 
created from a particular file in response to a user request to undo a particular file (see, 
e.g., Appellant's specification, paragraph [0062], paragraph [0078], paragraphs [0125]- 
[0127]; see also, e.g., data consolidator 450 illustrated at Fig. 4 and browser 311 
connected to financial fusion server 330 via corporate banking module 320). 

Appellant additionally argues based on dependent claims 16-17 including claim 
limitations pertaining to: a data consolidator identifying dependent files having 
transaction records dependent on transaction records created from said particular file (see, 
e.g., Appellant's specification, paragraph [0077], paragraphs [0102]-[104], paragraphs 
[0122]-[0124]; see also, e.g., data consolidator 450 illustrated at Fig. 4), wherein said 
dependent files are reprocessed by the data consolidator in response to the user request to 
undo the particular file (see, e.g., Appellant's specification, paragraph [0077], paragraphs 
[0102]-[104], paragraphs [0122]-[0127]; see also, e.g., data consolidator 450 illustrated at 
Fig. 4 and browser 311 connected to financial fusion server 330 via corporate banking 
module 320). 

Appellant additionally argues based on dependent claims 27 and 42, which 
include claim limitations pertaining to: a user-accessible system comprising a main back- 
end database system for a bank (see, e.g., Appellant's specification, paragraph [0048] 
(server connected to back end systems and databases), paragraph [0088] (database 
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repository), paragraph [0129] see also, e.g., host (back-end) 340 illustrated at Fig. 3 and 
live back-end system 470 at Fig. 4). 

Appellant additionally argues based on dependent claims 32 and 47, which 
include claim limitations pertaining to: ignoring any duplicate information already stored 
in the consolidation repository when consolidating financial information from a user- 
accessible system with financial information from a consolidation repository (see, e.g., 
Appellant's specification, paragraph [0072] (bill payment record from live system deleted 
as duplicated in BAI file), paragraph [0085]; see also, e.g., data consolidator 450 
illustrated at Fig. 4 connected to live back-end system 470 and repository 460 and 
consolidation of information from live system at step 509 at Fig. 5B). 

6. GROUNDS OF REJECTION TO BE REVIEWED 

The grounds for appeal are: 

(1st) Whether claims 1-2, 4-9, 18-22, 24, 28-31, 33-37, 39, 43-46, and 48 are 

unpatentable under 35 U.S.C. Section 103(a) as being obvious over US Patent 7,310,615 
of Lewis (hereinafter "Lewis") in view of U.S. Patent 7,194,402 of Poplawski 
(hereinafter "Poplawski"), further in view of U.S. Published Application 2001/0056387 
of Magary et al (hereinafter "Magary"); 

(2nd) Whether claims 3, 23, and 38 are unpatentable under 35 U.S.C. Section 
103(a) as obvious over Lewis (above), in view of Poplawski (above), further in view of 
Magary (above), and further in view of US Patent 6,856,970 of Campbell et al. 
(hereinafter "Campbell"); 

(3 rd ) Whether claims 10, 25, and 40 are unpatentable under 35 U.S.C. Section 
103(a) as obvious over Lewis (above), in view of Poplawski (above), further in view of 
Magary (above), and further in view of US Patent 6,71 1,715 of Grealish (hereinafter 
"Grealish"); 

(4 th ) Whether claim 11 is unpatentable under 35 U.S.C. Section 103(a) as obvious 
over Lewis (above), in view of Poplawski (above), further in view of Magary (above), 
and further in view of U.S. Published Application 2006/0080255 of Riehl et al 
(hereinafter "Riehl"); 

(5 th ) Whether claim 12 is unpatentable under 35 U.S.C. Section 103(a) as obvious 
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over Lewis (above), in view of Poplawski (above), further in view of Magary (above), 
further in view of Riehl (above) and further in view of U.S. Published Application 
2002/0004773 of Xu et al (hereinafter "Xu"); 

(6 th ) Whether claims 13-14, 26 and 41 are unpatentable under 35 U.S.C. Section 
103(a) as obvious over Lewis (above), in view of Poplawski (above), further in view of 
Magary (above), further in view of Riehl (above) and further in view of U.S. Patent 
5,754,655 of Hughes et al (hereinafter "Hughes"); 

(7 th ) Whether claim 15 is unpatentable under 35 U.S.C. Section 103(a) as obvious 
over Lewis (above), in view of Poplawski (above), further in view of Magary (above) and 
further in view of U.S. Published Application 2002/0044684 of Pelly (hereinafter 
Telly"); 

(8 th ) Whether claim 16 is unpatentable under 35 U.S.C. Section 103(a) as obvious 
over Lewis (above), in view of Poplawski (above), further in view of Magary (above) and 
further in view of U.S. Published Application 2002/0042795 of Smith (hereinafter 
"Smith"); 

(9 th ) Whether claim 17 is unpatentable under 35 U.S.C. Section 103(a) as obvious 
over Lewis (above), in view of Poplawski (above), further in view of Magary (above), 
further in view of Smith (above) and further in view of Pelly (above); 

(10 th ) Whether claims 27 and 42 are unpatentable under 35 U.S.C. Section 103(a) 
as obvious over Lewis (above), in view of Poplawski (above), further in view of Magary 
(above) and further in view of U.S. Published Application 2006/0041493 of Schulze et al 
(hereinafter "Schulze"); and 

(1 1 th ) Whether claims 32 and 47 are unpatentable under 35 U.S.C. Section 103(a) 
as obvious over Lewis (above), in view of Poplawski (above), further in view of Magary 
(above) and further in view of U.S. Published Application 2003/0120619 of Osborne 
(hereinafter "Osborne"). 

7. ARGUMENT 

A. First Ground: Claims 1-2, 4-9, 18-22, 24, 28-31, 33-37, 39, 43-46, and 48 rejected 
under 35 U.S.C. 103(a) 

1. General 
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Under Section 103(a), a patent may not be obtained if the differences between the 
subject matter sought to be patented and the prior art are such that the subject matter as a 
whole would have been obvious at the time the invention was made to a person having 
ordinary skill in the art to which the subject matter pertains. To establish a prima facie 
case of obviousness under this section, the Examiner must establish: (1) that there is 
some suggestion or motivation, either in the references themselves or in the knowledge 
generally available to one of ordinary skill in the art, to modify the reference or to 
combine reference teachings, (2) that there is a reasonable expectation of success, and (3) 
that the prior art reference (or references when combined) must teach or suggest all the 
claim limitations. (See e.g., MPEP 2142). The reference(s) cited by the Examiner fail to 
meet these conditions. 

2. Claims 1-2, 4-9,18-22, 24, 28-31, 33-37, 39, 43-46, and 48 
The Examiner has rejected Appellant's claims 1-2, 4-9,18-22, 24, 28-31, 33-37, 
39, 43-46, and 48 under 35 U.S.C. Section 103(a) as being obvious over US Patent 
7,310,615 of Lewis (hereinafter "Lewis") in view of U.S. Patent 7,194,402 of Poplawski 
(hereinafter "Poplawski"), further in view of U.S. Published Application 2001/0056387 
of Magary et al (hereinafter "Magary"). The following rejection of Appellant's claim 1 
by the Examiner is representative of the Examiner's rejection of the Appellant's claims 
under Section 103 based on Lewis, Poplawski and Magary: 

Regarding claim 1, Lewis discloses a system for consolidating financial 
transaction information from multiple sources for presentation to a user, the 
system comprising: a file importer for importing data files from a first source and 
processing each data file to create parsed information for each transaction present 
in the data file [Col.4 line 66- Col.5 line 12] . 

Lewis discloses a data consolidator for receiving parsed information from the file 
importer, consolidating said parsed information with transaction information from 
a user accessible system to create consolidated transaction records, [See Claim 1]. 
Lewis discloses wherein consolidating said parsed information includes removing 
transaction information derived from the user accessible system that is duplicated 
in said parsed information from the data files [Col. 17 lines 54-64]. 
Lewis discloses a reporting module for receiving a request for financial 
transaction information for a particular account and presenting consolidated 
transaction records for the particular account to the user in response to the request, 
wherein the user may navigate through said consolidated transaction records 
based upon said unique identifier [Col. 7 lines 21-24 and 47-49]. 
Lewis does not explicitly disclose represent any additional information present in 
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the data file in Extensible Markup Language (XML) format. However Poplawski 
discloses represent any additional information present in the data file in 
Extensible Markup Language (XML) format. At the time of the invention one 
would have been motivated to modify the disclosure of Lewis to include the 
teachings of Poplawski to obtain invention as specified in claim 1. The rationale 
to combine the teachings would be to convert large amounts of data quickly to an 
XML format. 

Lewis does not explicitly disclose assigning a unique identifier to each 
consolidated transaction record for an account, and storing said consolidated 
transaction records. However Magary teaches disclose assigning a unique 
identifier to each consolidated transaction record for an account, and storing said 
consolidated transaction records (Magary claim 9). At the time of the invention 
one would have been motivated to modify the disclosure of Lewis to include the 
teachings of Magary to obtain invention as specified in claim 1. The rationale to 
combine the teachings would be for warehousing financial transaction data for a 
plurality of financial transactions. 

(Final Rejection, paragraph 5, pages 3-4) 

In response to Appellant's previously filed Amendment, the Examiner withdrew 
the previous Section 102 rejection of the claims of this group based on Lewis. However, 
the Examiner has added two additional references to this first Section 103 rejection and 
now comes up with a total of eleven (11) different grounds for rejection of Appellant's 
claimed invention based on various combinations of twelve (12) different references — a 
very sizable collection. To be sure, there is no absolute cap or ceiling as to the number of 
references that may form a competent combination under Section 103, but the fact that 
the Examiner is having to go to so many places to string together eleven different 
"obviousness" rejections here begs the question what exactly is "obvious." At some 
point, the thread of logic used to weave together such a large number of references 
becomes stretched so thin that it breaks. In particular in the present application, it is 
respectfully submitted that the Examiner has combined together such a disparate and 
large collection of art, including references that have nothing to do with one another other 
than generally pertaining to computer-related technology, that the rejection does not 
establish obviousness under Section 103. 

Turning specifically to the first Section 103 rejection based on Lewis, Poplawski 
and Magary, the Examiner has added Magary and Poplawski in an effort to cure the 
acknowledged deficiencies of Lewis to Appellant's claimed invention. The Magary 
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reference, however, seems to have little relevance to Appellant's claimed invention. 
Magary describes taking a print stream of a monthly statement, check image or report and 
warehousing the document (see e.g., Magary, paragraph [0040]). The statement or report 
is stored keyed by client ID, account ID and document ID (see e.g., Magary, paragraph 
[0040]), indicating that individual transactions are not being stored by Magary's system 
nor can they be extracted individually from that system. Instead, a user of Magary's 
system can only receive (e.g., via email) an entire document such as, for example, a 
brokerage account statement for the month of December (see e.g., Magary, paragraph 
[0043] and paragraphs [0047]-[0048]). In contrast, Appellant's claimed invention 
provides that a user may navigate through individual transactions records. For example, 
Appellant's claim 1 includes the following claim limitations: 

a data consolidator for receiving parsed information from the file importer, 
consolidating said parsed information with transaction information from a user- 
accessible system to create consolidated transaction records, assigning a unique 
identifier to each consolidated transaction record for an account, and storing said 
consolidated transaction records, wherein consolidating said parsed information 
includes removing transaction information derived from the user accessible 
system that is duplicated in said parsed information from the data files; and 
a reporting module for receiving a request for financial transaction information 
for a particular account and presenting consolidated transaction records for the 
particular account to the user in response to the request, wherein the user may 
navigate through said consolidated transaction records based upon said unique 
identifier . 

(Appellant's claim 1, emphasis added). 

As illustrated above, Appellant's claimed invention enables a user to navigate 
through consolidated transaction records . Appellant's solution provides for ordering 
transaction information and assigning a unique identifier (e.g., sequence number) to each 
transaction stored in the repository (see e.g., Appellant's specification, paragraph [0069]). 
This unique identifier facilitates paging the transaction information to the user in 
manageable groups or "chunks" of information, such as in groups of ten transactions 
organized based on sequence number (see e.g., Appellant's specification, paragraphs 
[0069]-[0070]). The user may, for example, then navigate through the transactions in 
sequence based on the sequence number. This type of navigation isn't possible with 
Magary's solution as Magary's system only provides for retrieval of entire documents, 
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such as a monthly account statement for a given month. 

Also, the Examiner now acknowledges that the primary Lewis reference does not 
include teachings of representing additional information present in a data file being 
processed in Extensible Markup Language (XML) format and therefore adds Poplawski 
as providing such teachings. However, Poplawski simply describes a mechanism for 
converting tab- or comma-delimited flat files to XML format (see e.g., Poplawski, 
Abstract, Fig. 3). Here, the Examiner is essentially arguing that because one knows how 
to convert an entire flat file to XML format, one knows how to identify custom/extensible 
fields of transaction records (e.g., transaction data in BAI data files) and to handle this 
extra information which is not defined as a standard data element, convert it into XML 
format and store it in a data repository in XML format (see e.g., Appellant's specification, 
paragraph [0066]), while also storing other "standard" information in the repository in a 
different format. This argument is not convincing for the reasons discussed below. 

Appellant's claimed invention addresses one of the complications in processing 
records from different financial institutions in that different institutions frequently 
customize or extend the standard file format (e.g., BAI) to capture additional information . 
Appellant's solution operates to identify, capture and sort this extra information that is not 
defined as a standard data element in XML format. Thus, Appellant's solution stores 
"standard" information in columns and rows of a database and also captures and stores 
"extra" information in XML format (see e.g., Appellant's specification, paragraphs 
[0066]-[0067]). Poplawski, in contrast, describes performing a single conversion of a 
given flat file to XML format using a mapping file based on a given data type definition 
(see e.g., Poplawski, Fig. 3 and col. 4, lines 17-20). Poplawski makes no mention of how 
it would handle items of information that do not conform to the given data type 
definition, nor does Poplawski mention representing only certain portions of the 
information from the input file in XML format. Additionally, it should be noted that 
Lewis also makes no mention of processing data files containing additional (or extended) 
data fields. Instead Lewis' system is focused on receiving and processing individual real- 
time messages or batch files of messages (Lewis, col. 9, lines 10-22 and lines 44-48). 
Lewis' solution also relies on use of a schema (or rules) as to how incoming items of data 
are to be applied to the accounts, balances, and so forth represented in Lewis' system 
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(Lewis, col. 9, lines 48-59). Thus, neither Lewis' nor Poplawski's teachings are 
comparable to Appellant's claim limitations of identifying "extra" information in 
transaction records, converting that information into XML format and storing the 
information in a manner comparable to that of Appellant's claimed invention. 

Additionally, Appellant's solution not only handles transaction data that is 
received via a file, but also handles transaction data received from a live, user-accessible 
system (see e.g., Appellant's specification, paragraphs [0071]-[0072]). In this case, 
transaction data arrives via a programming object and is converted from object (e.g., 
HashMap) format to XML format. Thus, Appellant's claimed invention supports both 
file-based and object-based transactions with the same underlying mechanism and 
handles both "standard" data as well as custom or "extra" information. When transaction 
data from file or live sources is found to contain "extra" information, Appellant's solution 
converts this extra information to XML format for storage. This is dramatically different 
from the simple process of conversion of a delimited file to XML described by 
Poplawski. 

The fact that Appellant's solution operates to consolidate transaction data from 
multiple sources, including both a live, user-accessible systems as well as data imported 
from data files introduces further distinctions between Appellant's claimed invention and 
the prior art. Appellant's solution recognizes that today's real-time transactions are 
tonight's file-based transactions and therefore the two sets of sources (e.g., data files 
typically received and processed at night and real-time transaction data from "live" 
systems) include large quantities of duplicate data. Appellant's solution operates to 
consolidate data from multiple sources while also eliminating duplicate data by replacing 
real-time transaction data from the live system with the officially posted transaction data 
when the official transaction data is available (e.g., at the end of the day). This is 
described, for instance, in Appellant's specification as follows: 

Assume, for example, that a bank receives a set of BAI files once per day and 
processes these files each day at midnight. During a particular day, a user (i.e., 
bank account holder) may request account data for a particular account 1234. In 
response, the reporting module 480 may obtain current data from the live system 
470 and use the data consolidator 450 to add the live data into the data 
consolidator's repository 460. The combined information from the live system 
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and previously received data files relating to the particular account 1234 may then 
be displayed to the user in response to his or her request. The user may then issue 
a bill payment from this account at 2 pm in the afternoon of that same day. The 
data consolidator will update the account information to reflect the bill payment 
(based on information about the bill payment in the live system 470). That 
evening at midnight a new set of BAI files is received and processed, including a 
BAI file containing information relating to account 1234. The information in this 
BAI file may duplicate the information that came from the live system (e.g., 
because the BAI file includes a record of activity over the past 24 hours on 
account 1234). For example, the BAI file may include information reflecting the 
bill payment made from the account at 2 pm. When the system of the present 
invention processes data files (e.g., BAI files), the system will automatically 
purge any corresponding information in the repository which is marked as live 
from the user-accessible system. In this example, the bill payment record from 
the live system will be deleted as it is duplicated in the BAI file . 

(Appellant's specification, paragraph [0072], emphasis added) 

As illustrated above, the consolidation steps performed by Appellant's invention 
include removing duplicate transaction data. This feature is also described, for instance, 
in the above-cited claim limitations of Appellant's claim 1. The removal of duplicate 
transaction information reduces the quantity of the data that is maintained, provides 
increased consistency and improves performance. 

The Examiner references Lewis at col. 17, lines 54-64 as providing the 
corresponding teachings. However, the referenced portion of Lewis reads as follows: 

The Validation Process ensures the accuracy of the data and prevents duplicative 
entries. The Validation Process applies quality assurance rules, pre-defined by the 
user, to the incoming data. The data is compared against pre-existing records to 
discern any discrepancies, and to test for changes in excess of acceptable 
tolerances. Missing data is calculated or derived from other data, where possible. 
Errors and omissions trigger notifications, via the notification server, to the 
appropriate staff, who can then correct the data using a desktop application. Once 
completed, the Validation Process presents the enriched information to the 
Construction Process. 

(Lewis, col. 17, lines 54-64) 

Respectfully, Lewis simply mentions that a "Validation Process" may be used to 
prevent duplicate entries in incoming data without providing any further detail about 
what this Validation Process might entail. Thus, it is unclear to one having ordinary skill 
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in the art what Lewis' Validation Process might entail or how it is implemented. 
Additionally, Lewis' system is handling market data and not transaction data and 
therefore whatever validation steps are applied are likely to be quite different than those 
utilized by Appellant's solution which is specifically focused on consolidation of 
transaction records. 

3. Conclusion 

All told, Lewis, Poplawski and Magary, even if combined, do not include 
teachings of a consolidation system that consolidates real-time transaction data from a 
live system with file-based transaction data in a manner that avoids duplication of the 
data. Additionally, none of these prior art references includes teachings of gracefully 
handling additional data fields in input transaction records by converting such additional 
data to XML format and storing it in the repository as with Appellant's claimed invention. 
Additionally the prior art references do not include teachings of assigning a unique 
identifier to each transaction and using this identifier to assist the user in navigating 
through transaction data. Therefore as these references, even when combined, do not 
teach or suggest all of the claim limitations of Appellant's claims, it is respectfully 
submitted that claims 1-2, 4-9,18-22, 24, 28-31, 33-37, 39, 43-46, and 48 (as well as 
other claims) distinguish over the combined references and the rejection under Section 
103 should not be sustained. 

B. Second Ground: Claims 3, 23, and 38 rejected under 35 U.S.C. 103(a) 

1. Claims 3, 23, and 38 

Claims 3, 23, and 38 stand rejected under 35 U.S.C. 103(a) as being unpatentable 
over Lewis (above), in view of Poplawski (above), further in view of Magary (above), 
and further in view of US Patent 6,856,970 of Campbell et al. (hereinafter "Campbell"). 
As to these claims, the Examiner acknowledges that Lewis does not disclose a file 
importer including a file adapter for extracting data from a particular type of data and, 
therefore, adds Campbell as providing these teachings. 

Appellant's claims are believed to be allowable for at least the reasons cited above 
in Appellant's First Ground of Appeal (incorporated herein by reference) pertaining to 
the deficiencies of Lewis, Poplawski and Magary as to Appellant's invention. As these 
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claims are dependent upon, and incorporate the limitations of Appellant's independent 
claims, they are distinguishable for the reasons previously described in detail. Although 
Campbell describes a BAI format mapper which takes into account different 
interpretations of BAI used at different banks, it does not include any teaching of a 
system that consolidates real-time transaction data with file-based transaction data 
comparable to Appellant's claimed invention. Thus, it does not cure the deficiencies of 
the Lewis, Poplawski and Magary references as to Appellant's invention. 
2. Conclusion 

For the reasons discussed above, the combined references do not teach or suggest 
all of the claim limitations of Appellant's claims 3, 23, and 38 (or other claims). 
Therefore, as the combined references do not teach or suggest all the limitations of 
Appellant's claims it is respectfully submitted that Appellant's claimed invention is 
distinguishable over the prior art and that the Examiner's rejection under Section 103 
should not be sustained. 

C. Third Ground: Claims 10, 25, and 40 rejected under 35 U.S.C. 103(a) 

1. Claims 10, 25, and 40 

Claims 10, 25, and 40 stand rejected under 35 U.S.C. 103(a) as being 
unpatentable over Lewis (above), in view of Poplawski (above), further in view of 
Magary (above), and further in view of US Patent 6,71 1,715 of Grealish (hereinafter 
"Grealish"). Here, the Examiner acknowledges that Lewis does not teach assigning a 
unique identifier comprising a sequence number to a transaction record. The Examiner 
therefore adds Grealish as providing these teachings. 

Appellant's claims are believed to be allowable for at least the reasons cited above 
in Appellant's First Ground of Appeal (incorporated herein by reference) pertaining to 
the deficiencies of Lewis, Poplawski and Magary as to Appellant's invention. As these 
claims are dependent upon, and incorporate the limitations of Appellant's independent 
claims, they are distinguishable for the reasons previously described in detail. As 
Grealish does not provide any teaching of a system consolidating real-time transaction 
data with file-based transaction data, it does not cure the deficiencies of these references 
as to Appellant's invention. 
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Additionally, Appellant's solution provides for assigning a unique identifier to 
each transaction stored in the repository to facilitate paging the transaction information to 
the user as previously described and as included as claim limitations of Appellant's 
independent claims (e.g., Appellant's claim 1 discussed above and as described in 
Appellant's specification, for instance at paragraph [0069]). Appellant's claim 10 adds 
that this unique identifier comprises a sequence number. Although Graelish describes a 
sequence number, the sequence number is used in a different type of system for different 
purposes. Graelish's system tracks display state changes made to a complex display grid 
and as display state changes are made associates a sequence number with the display state 
change (Graelish, Abstract). When the display grid is restored, Graelish's system 
analyses the sequence numbers in sequence to determine whether a particular display 
state change needs to be saved and/or restored, so as to avoid unnecessary restorations of 
display state changes (Graelish, Abstract). However, Graelish makes no mention of 
transaction data or using the sequence number (unique identifier) to facilitate display of 
transaction data to a user and/or to allow a user to navigate through such data as provided 
in Appellant's specification and claims. 

2. Conclusion 

For the reasons discussed above, the combined references do not teach or suggest 
all of the claim limitations of Appellant's claims 10, 25, and 40 (or other claims). 
Therefore, as the combined references do not teach or suggest all the limitations of 
Appellant's claims it is respectfully submitted that Appellant's claimed invention is 
distinguishable over the prior art and that the Examiner's rejection under Section 103 
should not be sustained. 

D. Fourth Ground: Claim 11 rejected under 35 U.S.C. 103(a) 

1. Claim 11 

Claim 11 stands rejected under 35 U.S.C. 103(a) as being unpatentable over 
Lewis (above), in view of Poplawski (above), further in view of Magary (above), and 
further in view of U.S. Published Application 2006/0080255 of Riehl et al (hereinafter 
"Riehl"). As to these claims, the Examiner acknowledges that Lewis does not disclose 
assigning a sequence number per account and per type of transaction and, therefore, adds 
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Riehl as providing these teachings. 

Appellant's claim 1 1 is believed to be allowable for at least the reasons cited 
above in Appellant's First Ground of Appeal and Third Ground of Appeal (both 
incorporated herein by reference) pertaining to the deficiencies of Lewis, Poplawski, 
Magary and Graelish as to Appellant's invention. Additionally, Appellant notes that the 
Examiner has not included Graelish in the rejection of Appellant's claim 1 1 (or claim 12 
below), even though Graelish was included as a basis for rejection of intervening claim 
10. In any event, Riehl does not cure the above-described deficiencies of Lewis, 
Poplawski, Magary and Graelish (assuming Graelish is applicable) as to Appellant's 
invention. 

Riehl simply describes that a transaction entry contains pertinent details regarding 
the transaction including a transaction sequence number, transaction type, account 
number, dollar amount and so forth as follows: 

The transaction entry contains all pertinent details regarding the transaction 
including, for example: a transaction sequence number; the transaction type; 
account number; and the dollar amount . There are approximately two hundred and 
fifty different types of transactions which can be processed, but the back office is 
only concerned with approximately one hundred and thirty. In one embodiment of 
the present invention, the branches 150 only send the back office 170 transactions 
of the pertinent one hundred and thirty types. In an alternative embodiment, the 
branches 150 send records to the back office 170 related to all of the transactions 
conducted at the respective branches 150, regardless of type. In this embodiment, 
the back office 170 culls out only the types of transactions which require back 
office processing 

(Riehl, paragraph [0030], emphasis added). 

As illustrated above, Riehl does not include the specific teachings of Appellant's 
claim 1 1 of a data consolidator which assigns a sequence number "per account and per 
type of transaction" . Instead, Riehl describes that each transaction entry may have "a 
transaction sequence number". In contrast, Appellant's invention assigns sequence 
numbers per account and type of transaction so that at a subsequent point it can 
efficiently extract pages of information based on a range of sequence numbers for any 
particular account and type of transaction (see e.g., Appellant's specification, paragraph 
[0069]). Respectfully, the teachings of Riehl, even if cobbled together with the teachings 
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of the other references cited by the Examiner, are not at all comparable to these features 
of Appellant's claimed invention. 
2. Conclusion 

For the reasons discussed above, the combined references do not teach or suggest 
all of the claim limitations of Appellant's claim 1 1 (or other claims). Therefore, as the 
combined references do not teach or suggest all the limitations of Appellant's claims it is 
respectfully submitted that Appellant's claimed invention is distinguishable over the prior 
art and that the Examiner's rejection under Section 103 should not be sustained. 

E. Fifth Ground: Claim 12 rejected under 35 U.S.C. 103(a) 

1. Claim 12 

Claim 12 stands rejected under 35 U.S.C. 103(a) as being unpatentable over 
Lewis (above), in view of Poplawski (above), further in view of Magary (above), further 
in view of Riehl (above) and further in view of U.S. Published Application 2002/0004773 
of Xu et al (hereinafter "Xu"). As to claim 12, which depends on intervening claims 10 
and 11, as well as independent claim 1, the Examiner acknowledges that the Lewis, 
Poplawski, Magary and Riehl references do not disclose assigning consecutive sequence 
numbers to transaction records of a given type and adds yet another reference - Xu -- as 
providing these teachings. 

Appellant's claim 12 is believed to be allowable for at least the reasons cited 
above in Appellant's First Ground of Appeal, Third Ground of Appeal and Fourth 
Ground of Appeal (all incorporated herein by reference) pertaining to the deficiencies of 
Lewis, Poplawski, Magary and Riehl as to Appellant's invention. Xu does not cure the 
deficiencies of these references as to Appellant's invention. 

Xu simply describes a assigning a monotonically increasing sequence number for 
each certificate revocation list (CRL) issued by a given certificate authority (CA) (Xu, 
paragraph [0053]). Although Xu describes a monotonically increasing sequence number, 
Xu makes no mention of assigning consecutive sequence numbers "to transaction records 
of a given type for a particular account" as provided in the claim limitations of 
Appellant's claim 12. Additionally, Xu's solution is focused on certificate revocation list 
consolidation and access (Xu, Abstract), which is a rather different field from that of 
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Appellant's solution for consolidation of financial transaction records. Thus, Appellant 
respectfully believes that Xu's teachings are not analogous to Appellant's claimed features 
of a data consolidator that assigns consecutive sequence numbers to transaction records 
of a given type for a particular account. 
2. Conclusion 

For the reasons discussed above, the combined references do not teach or suggest 
all of the claim limitations of Appellant's claim 12 (or other claims). Therefore, as the 
combined references do not teach or suggest all the limitations of Appellant's claims it is 
respectfully submitted that Appellant's claimed invention is distinguishable over the prior 
art and that the Examiner's rejection under Section 103 should not be sustained. 

F. Sixth Ground: Claims 13-14, 26 and 41 rejected under 35 U.S.C. 103(a) 

1. Claim 13-14, 26 and 41 

Claims 13-14, 26 and 41 stand rejected under 35 U.S.C. 103(a) as being 
unpatentable over Lewis (above), in view of Poplawski (above), further in view of 
Magary (above), further in view of Riehl (above) and further in view of U.S. Patent 
5,754,655 of Hughes et al (hereinafter "Hughes"). 

Appellant's claims are believed to be allowable for at least the reasons cited above 
in Appellant's First Ground, Third Ground, Fourth Ground and Fifth Ground of 
Appeal (all incorporated herein by reference) pertaining to the deficiencies of Lewis, 
Poplawski, Magary and Riehl as to Appellant's invention. As these claims are dependent 
upon, and incorporate the limitations of Appellant's independent and/or intervening 
claims, they are distinguishable for the reasons previously described in detail above. 
Hughes does not cure the deficiencies of these other references. 

Hughes describes a system for remote purchase and bill payment transactions. 
Hughes system provides for a "retrieval reference number" which is generated to aid in 
tracking a transaction within the processing system. Hughes' retrieval reference number 
is based on the least significant digit of the year, the Gregorian date and a sequence 
number that is reset at the beginning of each day and incremented for each transaction 
served by a remote host system (see e.g., Hughes, col. 6, lines 56-60). Appellant's 
claimed invention, in contrast, provides for assigning sequence numbers to transaction 
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records of a given type for a particular account as described previously. Additionally, 
Appellant's solution provides for two alternative paging schemes and related sequence 
numbers that can be implemented by a user or organization (e.g., a bank) depending on 
its environment and its requirements (see e.g., Appellant's claim 14). These two paging 
schemes are referred to as "consecutive" and "date-based" paging. The format of the 
sequence numbers that are assigned are based on which type of paging scheme the 
customer has selected (see e.g., Appellant's specification, paragraph [0069]). The 
"consecutive" scheme provides for assigning consecutive sequence numbers, while the 
"date-based" scheme provides for sequence numbers that include calendar date 
information (see e.g., Appellant's specification, paragraph [0069]). Hughes system does 
not provide comparable features or flexibility. Instead, Hughes creates a reference 
number based on a combination of date (i.e., year and Gregorian date) and a sequence 
number which is reset each day. It does not give the user a choice of paging schemes or 
otherwise provide features comparable to those of Appellant's claimed invention. 
2. Conclusion 

For the reasons discussed above, the combined references do not teach or suggest 
all of the claim limitations of Appellant's 13-14, 26 and 41 (or other claims). Therefore, 
as the combined references do not teach or suggest all the limitations of Appellant's 
claims it is respectfully submitted that Appellant's claimed invention is distinguishable 
over the prior art and that the Examiner's rejection under Section 103 should not be 
sustained. 

G. Seventh Ground: Claim 15 rejected under 35 U.S.C. 103(a) 

1. Claim 15 

Claim 15 stands rejected under 35 U.S.C. 103(a) as being unpatentable over 
Lewis (above), in view of Poplawski (above), further in view of Magary (above) and 
further in view of U.S. Published Application 2002/0044684 of Pelly (hereinafter 
"Pelly"). Here the Examiner adds Pelly for its teachings of reverse data compression 
encoding, which the Examiner contends is somehow comparable to Appellant's data 
consolidation solution that operates to undo transaction records in response to user input. 

Appellant's claims are believed to be allowable for at least the reasons cited above 
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in Appellant's First Ground of Appeal (incorporated herein by reference) pertaining to 
the deficiencies of Lewis, Poplawski and Magary as to Appellant's invention. As these 
claims are dependent upon, and incorporate the limitations of Appellant's independent 
claims, they are distinguishable for the reasons previously described in detail. 

Additionally, the referenced teachings of Pelly describe data compression 
encoding and decoding, which Appellant does not believe are at all relevant to 
Appellant's solution for consolidation of financial transaction information. In particular, 
the claim limitations of Appellant's claim 15 provide for undoing transaction records 
derived from a particular file in response to a user request to undo the file. Pelly's 
solution makes no mention whatsoever of transaction records or undoing transaction 
records base on user input. Instead, its primary teachings relate to data compression 
processing and, therefore, Appellant does not understand how it is at all comparable or 
even relevant to Appellant's claimed invention. 

2. Conclusion 

For the reasons discussed above, the combined references do not teach or suggest 
all of the claim limitations of Appellant's claim 15 (or other claims). Therefore, as the 
combined references do not teach or suggest all the limitations of Appellant's claims it is 
respectfully submitted that Appellant's claimed invention is distinguishable over the prior 
art and that the Examiner's rejection under Section 103 should not be sustained. 

H. Eighth Ground: Claim 16 rejected under 35 U.S.C. 103(a) 

1. Claim 16 

Claim 16 stands rejected under 35 U.S.C. 103(a) as being unpatentable over 
Lewis (above), in view of Poplawski (above), further in view of Magary (above), and 
further in view of U.S. Published Application 2002/0042795 of Smith (hereinafter 
"Smith"). 

Claim 16 is dependent on claims 1 and 15 and is, therefore, believed to be 
allowable for at least the reasons cited above in Appellant's First Ground of Appeal and 
Seventh Ground of Appeal (both incorporated herein by reference) pertaining to the 
deficiencies of Lewis, Poplawski and Magary as to Appellant's invention. As these 
claims are dependent upon, and incorporate the limitations of Appellant's independent 
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claims, they are distinguishable for the reasons previously described in detail. Appellant 
also notes that although Claim 16 in dependent upon intervening claim 15, the Examiner 
has not cited Pelly in its rejection of claim 16, which is puzzling. In any event, Smith 
does not cure any of the deficiencies of Lewis, Poplawski and Magary (or Pelly). 

As described above, Appellant's claim 15 provides for undoing transaction 
records derived from a particular file in response to user input. Claim 16 provides further 
limitations of identifying dependent files having transactions records dependent upon the 
file that is being undone. Although Smith describes identifying files which are dependent 
upon one or more other files in a library, Smith makes no mention of undoing or 
reprocessing any files or dependent files as provided in Appellant's specification and 
claims. 

2. Conclusion 

For the reasons discussed above, the combined references do not teach or suggest 
all of the claim limitations of Appellant's claim 16 (or other claims). Therefore, as the 
combined references do not teach or suggest all the limitations of Appellant's claims, it is 
respectfully submitted that Appellant's claimed invention is distinguishable over the prior 
art and that the Examiner's rejection under Section 103 should not be sustained. 

I. Ninth Ground: Claim 17 rejected under 35 U.S.C. 103(a) 

1. Claim 17 

Claim 17 stands rejected under 35 U.S.C. 1 03(a) as being unpatentable over 
Lewis (above), in view of Poplawski (above), further in view of Magary (above), further 
in view of Smith (above) and further in view of Pelly (above). 

Appellant's claims are believed to be allowable for at least the reasons cited above 
in Appellant's First Ground, Seventh Ground and Eighth Ground of Appeal (all 
incorporated herein by reference) pertaining to the deficiencies of Lewis, Poplawski, 
Magary and Smith as to Appellant's invention. As these claims are dependent upon, and 
incorporate the limitations of Appellant's independent and intervening claims, they are 
distinguishable for the reasons previously described in detail. 

The Examiner has again added Pelly for its teachings of reverse data compression 
encoding arguing that this is somehow comparable to Appellant's claim 17 which 
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includes claim limitations of reprocessing dependent data files (e.g., those dependent 
identified as described in claim 16) in response to the user request to undo the particular 
file (e.g., as described in claim 15). As previously discussed, Pelly's primary teachings 
relate to data compression processing and Pelly makes no mention whatsoever of 
transaction records or undoing transaction records and therefore appears to be of no 
relevance whatsoever to Appellant's claimed invention. 
2. Conclusion 

For the reasons discussed above, the combined references do not teach or suggest 
all of the claim limitations of Appellant's claim 17 (or other claims). Therefore, as the 
combined references do not teach or suggest all the limitations of Appellant's claims it is 
respectfully submitted that Appellant's claimed invention is distinguishable over the prior 
art and that the Examiner's rejection under Section 103 should not be sustained. 

J. Tenth Ground: Claims 27 and 42 rejected under 35 U.S.C. 103(a) 

1. Claims 27 and 42 

Claims 27 and 42 stand rejected under 35 U.S.C. 103(a) as being unpatentable 
over Lewis (above), in view of Poplawski (above), further in view of Magary (above), 
and further in view of U.S. Published Application 2006/0041493 of Schulze et al 
(hereinafter "Schulze"). As to these claims, the Examiner acknowledges that Lewis, 
Poplawski and Magary fail to disclose that the user-accessible system comprises a main 
back-end database system for a bank and, therefore, adds Schulze as providing these 
teachings. 

Appellant's claims are believed to be allowable for at least the reasons cited above 
in Appellant's First Ground of Appeal (incorporated herein by reference) pertaining to 
the deficiencies of Lewis, Poplawski and Magary as to Appellant's invention. As these 
claims are dependent upon, and incorporate the limitations of Appellant's independent 
claims, they are distinguishable for the reasons previously described in detail. The 
referenced teachings of Schulze simply describe making a back-up file of downloaded 
identification data and routing codes and storing it in an off-site storage system. These 
teachings do not appear comparable to the specific claim limitations of Appellant's claims 
27 and 42 and certainly do not cure the various other deficiencies of the other references 
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as to Appellant's claimed invention discussed in detail above. 
2. Conclusion 

For the reasons discussed above, the combined references do not teach or suggest 
all of the claim limitations of Appellant's claims 27 and 42 (or other claims). Therefore, 
as the combined references do not teach or suggest all the limitations of Appellant's 
claims it is respectfully submitted that Appellant's claimed invention is distinguishable 
over the prior art and that the Examiner's rejection under Section 103 should not be 
sustained. 

K. Eleventh Ground: Claims 32 and 47 rejected under 35 U.S.C. 103(a) 

1. Claims 32 and 47 

Claims 32 and 47 stand rejected under 35 U.S.C. 103(a) as being unpatentable 
over Lewis (above), in view of Poplawski (above), further in view of Magary (above), 
and further in view of further in view of U.S. Published Application 2003/0120619 of 
Osborne (hereinafter "Osborne"). 

Appellant's claims are believed to be allowable for at least the reasons cited above 
in Appellant's First Ground of Appeal (incorporated herein by reference) pertaining to 
the deficiencies of Lewis, Poplawski and Magary as to Appellant's invention. As these 
claims are dependent upon, and incorporate the limitations of Appellant's independent 
claims, they are distinguishable for the reasons previously described in detail. Osborne 
does not cure any of the deficiencies of these references as Osborne describes a solution 
for remote monitoring and diagnosing of industrial equipment which makes no mention 
of transaction information or how such transaction information may be consolidated for 
display to a user. 

2. Conclusion 

For the reasons discussed above, the combined references do not teach or suggest 
all of the claim limitations of Appellant's claims 32 and 47 (or other claims). Therefore, 
as the combined references do not teach or suggest all the limitations of Appellant's 
claims it is respectfully submitted that Appellant's claimed invention is distinguishable 
over the prior art and that the Examiner's rejection under Section 103. 
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L. Conclusion 

Appellant's invention greatly improves the efficiency of the task of consolidating 
financial information from live, user accessible systems with data received from file- 
based sources that avoids storing duplicate information and facilitates user navigation of 
the consolidated transaction data. It is respectfully submitted that the present invention, 
as set forth in the pending claims, sets forth a patentable advance over the art. 

In view of the above, it is respectfully submitted that the Examiner's rejection of 
Appellant's claims under 35 U.S.C. Section 103 should not be sustained. If needed, 
Appellant's undersigned attorney can be reached at 925 465 0361. For the fee due for this 
Appeal Brief, please refer to the attached Fee Transmittal Sheet. This Appeal Brief is 
submitted electronically in support of Appellant's Appeal. 

Respectfully submitted, 

Date: December 9, 2008 /G. Mack Riddle/ 

G. Mack Riddle; Reg. No. 55,572 
Attorney of Record 

925 465 0361 
925-465-8143 FAX 
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8. CLAIMS APPENDIX 



1. A system for consolidating financial transaction information from multiple 
sources for presentation to a user, the system comprising: 

a file importer for importing data files from a first source and processing each 
data file to create parsed information for each transaction present in the data file and 
represent any additional information present in the data file in Extensible Markup 
Language (XML) format; 

a data consolidator for receiving parsed information from the file importer, 
consolidating said parsed information with transaction information from a user-accessible 
system to create consolidated transaction records, assigning a unique identifier to each 
consolidated transaction record for an account, and storing said consolidated transaction 
records, wherein consolidating said parsed information includes removing transaction 
information derived from the user accessible system that is duplicated in said parsed 
information from the data files; and 

a reporting module for receiving a request for financial transaction information 
for a particular account and presenting consolidated transaction records for the particular 
account to the user in response to the request, wherein the user may navigate through said 
consolidated transaction records based upon said unique identifier. 

2. The system of claim 1, wherein said file importer includes at least one file 
adapter for extracting data from a particular type of data file. 

3. The system of claim 2, wherein said at least one file adapter includes a Bank 
Administration Institute (BAI) file adapter for extracting data from a Bank 
Administration Institute (BAI) data file. 

4. The system of claim 1, wherein said file importer is user extensible to extract 
data from additional types of data files. 

5. The system of claim 1, wherein said file importer is invoked at periodic 
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intervals to process data files received from said first source. 



6. The system of claim 1, wherein said first source is an external source. 

7. The system of claim 6, wherein said external source is a financial institution. 

8. The system of claim 1, wherein said data consolidator creates consolidated 
transaction records based on transaction information in the user-accessible system that is 
more recent than information from the data files received from the first source. 

9. The system of claim 1, wherein said XML representation is stored by the data 
consolidator for retrieval in response to a user request for financial transaction 
information. 

10. The system of claim 1, wherein said unique identifier assigned to a 
transaction record comprises a sequence number. 

11. The system of claim 10, wherein said data consolidator assigns a sequence 
number per account and per type of transaction. 

12. The system of claim 11, wherein said data consolidator assigns consecutive 
sequence numbers to transaction records of a given type for a particular account. 

13. The system of claim 11, wherein said data consolidator assigns date -based 
sequence numbers to transaction records of a given type for a particular account. 

14. The system of claim 1, wherein the data consolidator is user configurable to 
assign a unique identifier to transaction records using a selected one of consecutive 
sequence numbers and date-based sequence numbers. 

15. The system of claim 1, wherein the data consolidator provides for undoing 
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transaction records created from a particular file in response to a user request to undo a 
particular file. 

16. The system of claim 15, wherein the data consolidator identifies dependent 
files having transaction records dependent on transaction records created from said 
particular file. 

17. The system of claim 16, wherein said dependent files are reprocessed by the 
data consolidator in response to the user request to undo the particular file. 

18. The system of claim 1, wherein the reporting module presents at least one 
page containing said consolidated transaction records in a user interface. 

19. The system of claim 18, wherein a user may select a particular page of said 
consolidated transaction records for viewing in the user interface. 

20. The system of claim 1, wherein the reporting module retrieves consolidated 
transaction records matching criteria specified by the user in the request for financial 
transaction information. 

21. A computer-implemented method for consolidating and presenting financial 
information to a user, the method comprising: 

importing data files of different types; 

for each particular type imported, loading a file adapter suited for processing that 
particular type; 

for each imported data file, creating parsed information from the data file that 
identifies each transaction present in the data file with a unique sequence number, and 
that represents any additional information present in the data file in XML format; 

creating consolidated financial information by storing all parsed information in a 
consolidation repository, including removing financial information derived from a user 
accessible system which is duplicated in said parsed information; 
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receiving a user request at the user-accessible system for information about a 
particular financial account; and 

in response to the user request, determining financial information in the user- 
accessible system and the consolidation repository that is most current for the particular 
financial account, and presenting that financial information to the user. 

22. The method of claim 21, wherein the importing step occurs at periodic 
intervals. 

23. The method of claim 21, wherein the data file's file type comprises a BAI file 
type, and wherein the file adapter is suited for processing BAI files. 

24. The method of claim 21, wherein the file adapter is implemented as a 
pluggable architecture for supporting a particular file type. 

25. The method of claim 21, wherein each sequence number assigned is a unique 
identifier. 

26. The method of claim 21, wherein each sequence number assigned is a date- 
based sequence number. 

27. The method of claim 21, wherein the user-accessible system comprises a 
main back-end database system for a bank. 

28. The method of claim 21, wherein each imported data file is received from an 
external source. 

29. The method of claim 28, wherein the external source is a banking institution. 

30. The method of claim 21, wherein the consolidation repository stores financial 
information in database tables. 
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31. The method of claim 21, wherein the determining step includes consolidating 
financial information from the user-accessible system with financial information from the 
consolidation repository. 

32. The method of claim 31, wherein any duplicate information already stored in 
the consolidation repository is ignored. 

33. The method of claim 21, further comprising: 

for any new financial information in the user-accessible system that is not already 
present in the consolidation repository, creating new parsed information from the new 
financial information that identifies each transaction present with a unique sequence 
number, and that represents any additional information present in the data file in XML 
format; and 

updating the consolidated financial information in the consolidation repository to 
include the new parsed information. 

34. A computer-readable medium having processor-executable instructions for 
performing the method of claim 21. 

35. A downloadable set of processor-executable instructions for performing the 
method of claim 21. 

36. A computer-implemented system for consolidating and presenting financial 
information to a user comprising: 

a file importer for importing data files of different types; 

a plurality of file adapters, each file adapter suited for processing a particular type 
of data file imported by creating parsed information from the data file that identifies each 
transaction present in the data file with a unique sequence number, and by representing 
any additional information present in the data file in XML format for each imported data 
file; 
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a consolidator for consolidating financial information by consolidating parsed 
information from imported data files with data from a user- accessible system, including 
removing transaction information derived from the user accessible system duplicated in 
said parsed information; 

a consolidation repository for storing consolidated financial information; 

a user-accessible system for receiving a user request for information about a 
particular financial account; and 

a module for determining financial information in the user- accessible system and 
the consolidation repository that is most current for the particular financial account, and 
presenting that financial information to the user. 

37. The system of claim 36, wherein the file importer operates at periodic 
intervals. 

38. The system of claim 36, wherein one type comprises a BAI file type, and 
wherein one of the file adapters is suited for processing BAI files. 

39. The system of claim 36, wherein the file adapters are implemented as a 
pluggable architecture for supporting different file types. 

40. The system of claim 36, wherein each sequence number assigned is a unique 
identifier. 

41. The system of claim 36, wherein each sequence number assigned is a date- 
based sequence number. 

42. The system of claim 36, wherein the user- accessible system comprises a main 
back-end database system for a bank. 

43. The system of claim 36, wherein each imported data file is received from an 
external source. 
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44. The system of claim 43, wherein the external source is a banking institution. 

45. The system of claim 36, wherein the consolidation repository stores financial 
information in database tables. 

46. The system of claim 36, wherein the module for determining and presenting 
consolidates financial information from the user-accessible system with financial 
information from the consolidation repository. 

47. The system of claim 46, wherein any duplicate information already stored in 
the consolidation repository is ignored. 

48. The system of claim 36, further comprising: 

a module for updating the parsed information with new financial information any 
new financial information in the user-accessible system that is not already present in the 
consolidation repository. 
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9. EVIDENCE APPENDIX 

This Appeal Brief is not accompanied by an evidence submission under §§ 1.130, 
1.131, or 1.132. 
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10. RELATED PROCEEDINGS APPENDIX 

Pursuant to Appellant's statement under Section 2, this Appeal Brief is not 
accompanied by any copies of decisions. 



